Avoid a crash on method callables in generic array arguments - #6701

please bisect which commit broke this

Bisected to 7a8c43cf265f16625a9d626d1fa6637bf505d9fa, which introduced gatherArrayArgTypeSkeleton().

Its parent dfe44f6c7 analyses the method-callable regression without errors; that commit throws ShouldNotHappenException from getFirstClassCallableType(). I confirmed both with their identical committed dependency lockfile. The new skeleton path passes an unwalked MethodCall to the initializer resolver, where that first-class-callable case was missing.

Rebased onto current 2.3.x to resolve the Turbo pin conflict; the implementation is unchanged. Full suites pass with and without Turbo (22,459 tests each), and the rebuilt native version and parity checks pass. New-head CI is running.

Thanks! The crash is fixed for the reported snippet, but I don't think returning Closure for MethodCall is the right fix. gatherArrayArgTypeSkeleton() asks InitializerExprTypeResolver about expressions that aren't constant expressions, and this PR only covers one of them.

1. Other first-class callables still crash on this branch

getFirstClassCallableType() still throws for a FuncCall whose name is an expression:

/**
 * @template T
 * @param array{producer: callable(): T, consumer: callable(T): void} $pair
 */
function pipe(array $pair): void {}

function a(\Closure $f): void
{
	pipe(['producer' => $f(...), 'consumer' => function ($v): void {}]);        // Internal error
	pipe(['producer' => 'strlen'(...), 'consumer' => function ($v): void {}]);  // Internal error
}

2. A method callable gives a less precise type than its equivalent forms

The skeleton exists to type the closures nested in the array. A plain Closure leaf resolves T to mixed. Every other way of writing the same callable resolves it to int:

class Producer
{
	public function produce(): int { return 1; }
	public static function produceStatic(): int { return 1; }
}

function test(Producer $p): void
{
	pipe(['producer' => $p->produce(...), 'consumer' => function ($v): void {
		\PHPStan\dumpType($v); // mixed
	}]);

	$callable = $p->produce(...);
	pipe(['producer' => $callable, 'consumer' => function ($v): void {
		\PHPStan\dumpType($v); // int
	}]);

	pipe(['producer' => Producer::produceStatic(...), 'consumer' => function ($v): void {
		\PHPStan\dumpType($v); // int
	}]);
}

I'd fix this in gatherArrayArgTypeSkeleton() itself rather than in InitializerExprTypeResolver:

• For a MethodCall first-class callable whose receiver has a scope-known type (findScopeStateType($expr->var, $scope)), build the type from the method's variants via createFirstClassCallable().
• For anything else that needs a walk (anonymous class receivers, $f(...), 'strlen'(...)), return mixed. That is what the skeleton's own docblock promises ("mixed for anything that needs a walk"), and it covers point 1 without a new case per node type.

3. Not caused by this PR, but it's in the same code: the skeleton reads stale scope state

Leaves are priced from the scope before the array is evaluated. A sibling that changes state earlier in the array therefore gives the nested closure a wrong type, not just a less precise one. This is a false positive in 2.3.x that 2.2.x doesn't report:

/**
 * @template T
 * @param array{first: mixed, value: T, callback: callable(T): void} $spec
 */
function run(array $spec): void {}

function fp(): void
{
	$i = 0;
	run([
		'first' => $i++,
		'value' => $i,                  // skeleton prices this as 0, at runtime it's 1
		'callback' => function ($v): void {
			if ($v === 1) {             // "Strict comparison using === between 0 and 1 will always evaluate to false."
				echo 'one';
			}
		},
	]);
}

The same happens with 'w' => $x = 'str', 'v' => $x ($v is 1, $r is 'str') and with 'w' => $this->reset(), 'v' => $this->prop ($v is still the narrowed 5). The skeleton should stop trusting scope state for every leaf that comes after the first element that can change scope (assignments, ++/--, impure calls, by-ref arguments) and use mixed for those leaves instead.

Results are the same with and without bleeding edge. The skeleton never reaches TemplateArgumentObserver::collectArgument() or observeUnpackedArgument(): the walk overwrites $gatheredArgTypeByIndex[$i] before either is called. It only affects the parameter type the array literal is walked with, so the problem is confined to the closures nested in the array.

Thanks for the detailed examples. I moved the fix into the array skeleton and removed the initializer fallback. Scope-known method callables now retain their variants, while walk-dependent callable expressions use mixed without an eager receiver walk. The skeleton also stops trusting pre-array state after potentially state-changing keys or values, including nested arrays. The new type regressions pass with and without bleeding edge; full PHP and Turbo suites pass (22,476 tests each), including the existing incompatible-callable control. New-head CI is running.